web: add web-app server for development and production builds #20126
Conversation
valerybugakov
added
ops & tools & dev
frontend-platform
valerybugakov
force-pushed
the
vb/web-server
branch
from
9e5f5a0
to
5400089
Compare
There was a problem hiding this comment.
Nice work 🎊
I would be worried a bit about people messing with sourcegraph.com, but maybe that's not a reasonable fear :) I think we should not make it serve on sourcegraph.test:3443, though because it's too easy to think it's a safe dev environment.
- A static mock is used instead of the JS context returned from the SOURCEGRAPH_API_URL.
I think that should be implemented soon. The flags set change a lot about the app behavior and it is also dynamic in the backend so if I change a config, the jscontext would change if it was a real deployed app.
- index.html template is different from what we have in cmd/frontend/internal/app/ui/app.html. We should reuse it to be consistent with the default production setup.
Definitely agree. Also it's so easy to forget about this file when someone updates the app.html file.
| @@ -0,0 +1,65 @@ | |||
| import 'dotenv/config' | |||
There was a problem hiding this comment.
Now that we already have quite a few packages, I think this should be it's own package under client/dev-server or whatever. That way, this package will still be only code required in the webapp, and it's not as easy to accidentally import webpack and such into the final web bundle (accidentally imported from this file, for example). Also the dev server needs commonjs as a target, and the webapp can be esnext, so maybe another indicator that a proper package with it's own tsconfig.json file might make sense here.
There was a problem hiding this comment.
This is the right call. I thought about doing it in this PR. Still, apart from this change, we need to extract shared Webpack configuration into a standalone package to avoid adding loaders to three different configs: Web, Browser, and Storybook. I believe this step should be done before extracting client/dev-server because it might result in duplicated work and circular dependencies between web and dev-server packages. First, move configs to a shared package. Then extract dev-server and use shared configs.
Co-authored-by: Erik Seliger <erikseliger@me.com>
|
I'm really excited to enable web dev without needing any backend services. |
|
Something we may want to consider is injecting some kind of banner somewhere "THIS USES PRODUCTION DATA FROM sourcegraph.com" because it may be easy to forget if you have multiple or old tabs open given this runs on localhost. I feel like it may otherwise only be a matter of time until someone accidentally misconfigures an external service on dotcom or something |
valerybugakov
added
the
dx
|
Nice work. I don't think this is a blocker for this, but just the thing which we should notice -
|
Updates
|
This PR introduces an independent server for the web application, which can use any deployed API instance as a backend.
Independent web app server
This PR introduces an independent server for the web application which can use any deployed API instance as a backend.
Context
While working on the CSS modules configuration, I needed a way to iterate quickly on the
webpack.config.jsand test changes in the production environment: runyarn build-weband check how CSS modules are loaded in the application. There was no easy/quick way to do it. @umpox found out that it's possible to change a couple of variables in thestart.shscript to serve the production build. But this solution was quite slow because of the backend services involved.To solve this, I've configured a minimum viable server to serve web app production artifacts without our backend services. I've added HtmlWebpackPlugin to our
webpack.config.jsto produceindex.htmland configured Webpack dev server proxy to point the server to the deployed API instance. It allowed testing changes in production build without backend services quickly. This PR is the enhanced version of this setup.How it works
WEBPACK_SERVE_INDEX=true. This plugin outputsindex.htmlto theui/assets.SOURCEGRAPH_API_URLprovided in the.envfile using the http-proxy-middleware.CSRF token is invalidAPI error CSRF token is retrieved from theSOURCEGRAPH_API_URLbefore the server starts. Then this value is used for every subsequent request to the API.sgscookie, all cookies from the API requests are propagated to the local client.Known issues
The issues listed below can be addressed in separate PRs. They are non-blocking for the functionality this PR introduces and doesn't affect existing workflows. We can iterate on each individual issue once we have the foundation in place.
site-config.jsonis used instead of the JS context returned from theSOURCEGRAPH_API_URL.gulpfile.js. They should be shared with it after migration to Typescript.index.htmltemplate is different from what we have incmd/frontend/internal/app/ui/app.html. We should reuse it to be consistent with the default production setup.Changes
client/web/package.json:yarn serve:devandyarn serve:prod.devdirectory is added to theclient/webpackage. It contains the server configuration used by the commands above..env.exampleis added to theclient/webto showcase the example env configuration.require('ts-node').register()is added to thegulpfile.jsto allow TS usage forhtml-webpack-pluginconfiguration.Updates
sgCLI tool:sg run web-standalonesg run enterprise-web-standalonesg run web-standalone-prodsg run enterprise-web-standalone-prod.env.exampleanddotenvpackage becauseenvvariables are now defined insg.config.yaml.